• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    Methods and systems related to providing a secure connection are described. One method described includes storing a device secret in a secure element on a first device, storing a mapping of the device secret to a device identifier of the first device in a cloud architecture, generating a pairing key using a first key generator connection protocol in the secure element and in the device secret, generate the pairing key using a second connection protocol key generator in the cloud architecture and in the device secret. The method also includes transmitting the pairing key from the cloud architecture to a second device in response to receiving the device identifier, mutually authenticating the first and second device using the pairing key, and adding the secure connection to the interdevice connection using the key of pairing as stored on the first device and as stored on the second device.
    公开号:BR102019015369B1
    申请号:R102019015369-5
    申请日:2019-07-25
    公开日:2021-03-16
    发明作者:Brian Jeremiah Murray；Narayanan Gopalakrishnan
    申请人:Clover Network, Inc；
    IPC主号:
    专利说明:

    BACKGROUND
    [001] Establishing secure connections between communication devices is essential to preserve the privacy and data integrity of the information that passes between them. Wireless connections are particularly vulnerable to attack from malicious entities that could use other nearby wireless devices to carry out this type of attack. Current security methods are designed to withstand the most common types of attacks, such as man-in-the-middle attacks (MITM), denial of service attacks (DoS) or resolution protocol poisoning attacks address (ARP). While many of the nuances of secure communication vulnerabilities are known, choosing a specific security configuration for a given set of wirelessly connected devices is not trivial. For example, a security configuration can be highly dependent on the unique capabilities of software and hardware architectures on a type of device, such as the significant features available for a personal computer system connected to a Wi-Fi router. Alternatively, devices Wireless communication devices can rely on short-range communication, such as in the case of a smartphone using near-field communication, to provide a level of security using the limited range of wireless transmission. To meet this constantly evolving context, new connection security solutions are under constant development.
    [002] Devices that communicate via wireless inter-device connections generally collaborate on a system or network, as exemplified in the growing paradigm of the Internet of Things (IoT). Since many of these devices are dependent on private information, establishing secure connections between two or more devices is a common need in personal, home and corporate settings. A general example covering these configurations includes the secure connection between a multifunctional personal user device, such as a smartphone, and an application device, sometimes called a “dongle” or peripheral device. Personal user devices use a set of communication protocols to maximize security and cross-device compatibility, while application devices are designed with limited hardware and software in order to have a convenient form factor for personal use and remain competitive in the market. Driven by this asymmetry in the functionality of the device, the establishment of a secure connection between a personal user device and an application device can be limited by the application device. Careful consideration must be given to the design of a system to provide such a connection that has usability and security.
    [003] The Transport Layer Security (TLS) protocol is a customizable and well-developed security protocol that can be used to protect a wireless communication connection between a personal user device and an application device. TLS can be configured to provide a secure connection using symmetric or asymmetric key encryption schemes. Authentication with TLS can be established using methods defined by the public key infrastructure (PKI) framework, for example, with the use of certificates signed by a trusted third party. In addition, two or more devices can establish secure communication through a process in which a TLS server is instantiated on one device, while the other devices can communicate with the TLS server as clients. Subsequently, the server and the clients can negotiate the desired key authentication and encryption schemes through a process called “handshake”, in which both agree on methods of predefined series of executable algorithms and transfers of server-client information. It is of utmost importance that the methods of authentication and key encryption within the handshake are implemented with the system's unique devices in mind to enable the maximum security potential of the secure connection. SUMMARY
    [004] Methods and systems related to providing a secure connection with an inter-device connection are described. A system includes a first device, a second device and a cloud architecture. The first device has a secure element that stores a device secret, instantiates a first connection protocol module, and instantiates a first connection protocol key generator. The cloud architecture stores a mapping from the device secret to an identification of the first device and instantiates a second connection protocol key generator. The first connection protocol key generator and the second connection protocol key generator are configured to generate a pairing key using the device secret. The second device has a processor that instantiates a second connection protocol module, which is communicatively connected to the first device through the inter-device connection, which is configured to receive the identification of the first device from the first device, and which is configured to switch the identification of the first device for pairing key with the cloud architecture in a network connection. The first connection protocol module and the second connection protocol module are configured to authenticate each other using the pairing key and add the secure connection to the interdevice connection using the pairing key.
    [005] One method described includes storing a device secret in a secure element on the first device, and storing a mapping from the device secret to a device identifier of the first device in a cloud architecture. The method includes generating a pairing key using a first connection protocol key generator over the secure element and the device secret, and generating the pairing key using a second connection protocol key generator over the cloud architecture and the device key. The method includes transmitting the pairing key from the cloud architecture to the second device in response to receiving the device identifier. The method includes mutually authenticating the first and second devices using the pairing key as stored on the first device and as stored on the second device. The method includes adding the secure connection to the interdevice connection using the pairing key as stored on the first device and stored on the second device.
    [006] A system comprises a first device, a second device, a secure element, a cloud architecture, a first connection protocol key generator, a second connection protocol key generator, a first connection protocol module , an application and a second connection protocol module. The first device and the second device are connected with an inter-device connection. The first device has a secure element that stores a device secret. The cloud architecture stores the device secret and a mapping from the device secret to a device identifier for the first device. The first generation protocol key generator is in the secure element configured to generate a pairing key using the device secret. The second connection protocol key generator is in the cloud architecture configured to generate the pairing key using the device secret. The secure element in the first device instantiates the first connection protocol module. The second connection protocol module is on the second device. The application is on the second device, receives the pairing key from the cloud architecture and instantiates the second connection protocol module. The cloud architecture is configured to pass the pairing key to the second device in response to receiving the device identifier. The first connection protocol module and the second connection protocol module are configured to mutually authenticate using the pairing key and add a secure connection to the interdevice connection using the pairing key. BRIEF DESCRIPTION OF THE DRAWINGS
    [007] Fig. 1 illustrates a system for providing a secure connection to an inter-device connection between a first device and a second device, aided by a cloud architecture.
    [008] Fig. 2 illustrates the system of Fig. 1, in which the provision of the secure connection uses an OTP key encryption method to generate a pairing key.
    [009] Fig. 3 illustrates a flowchart and block diagram that describe an example of the OTP key encryption method used by the system in Fig. 2.
    [010] Fig. 4 illustrates the system in Fig. 2 with additional security and communications elements and modules for the cloud architecture.
    [011] Fig. 5 illustrates the system in Fig. 4 with additional elements and modules that allow the system to be used with secure payment data. DETAILED DESCRIPTION
    [012] Specific methods and systems for providing a secure connection between two devices according to the above summary are provided in this section. The methods and systems described in this section are non-limiting embodiments of the invention and are provided for explanatory purposes only. The detailed description of these specific modalities should not be applied to restrict the full scope of the invention.
    [013] In specific embodiments of the invention, a system is provided to add a secure connection to an inter-device connection between communication devices. For example, the secure connection can be a transport layer security (TLS) connection that uses the TLS protocol together with a shared secret that is directly provided or derived from the two devices. As another example, the secure connection can be a datagram transport layer (DTLS) security connection. Throughout this description, TLS will be used as an exemplary connection type and protocol. However, the secure connection can involve other protocols in which a single key is used to provide confidentiality and integrity for a two-way flow of data.
    [014] Establishing a secure connection begins with authentication. Authentication is the process in which a user, device, application, server, cloud architecture or other defined system entity provides its identity to a third party of communication. Mutual authentication between two system entities is a two-way authentication process. In the TLS protocol, the identity of the TLS server is authenticated to protect the client from being inadvertently compromised by sharing private information with a malicious third party. When bidirectional information transfer must be protected, for example, in secure communication from a first device and a second device described here, mutual authentication is desired. In principle, mutual authentication can be performed using a variety of encryption schemes. For example, the X.509 public key standard allows an authentication scheme using public keys contained in signed certificates to authenticate a server to a client that has a corresponding private key. More generally, public / private key encryption methods can be used in a system established within a public key infrastructure (PKI) environment. The public / private key encryption paradigm is robust using sufficiently complex key generation methods and e-authentication methods implemented by trusted third parties. Symmetric keys can also be used for mutual authentication. A “symmetric key” can refer to a single cryptographic key maintained by two communication parties. The use of symmetric keys for mutual authentication can be made possible, for example, by both parties having access to a mutually known set of secret data. Symmetric key encryption and authentication protocols have relatively low computational and memory requirements, compared to public / private keys, and can be used to streamline security handshakes even on simple devices.
    [015] Multiple encryption and authentication schemes are available to provide a secure connection using the TLS protocol. The choice of the scheme is negotiated in a process called handshake before the start of the supply. The handshake involves a set of predefined methods known to both parties in communication. An example of a TLS handshake can be performed as follows. First, a shared secret is generated between a server and a client over an insecure connection by exchanging local session information from the server and client in combination with an agreed number or data set generated by an algorithm called a pre secret key -master (“pre-master”). Second, the server and the client proceed with a pre-programmed and secretly agreed transformation to transform the secret pre-master key into a secret master key. The transformation must be computationally difficult to reverse to securely generate an encryption key over an unsecured connection. A Diffie-Hellman key exchange is an example of a method that can be used to perform the first and second steps described. Third, the master secret key is used by both parties to make a secret message authentication code (MAC) key to be used during the session for additional generation of a symmetric session key that can be used again by both parties to encrypt and decrypt communication data.
    [016] In specific embodiments of the invention, the generation of the secure connection can be based on a set of secret data called a “seed” with which a cryptographic key can be generated. The seed can be any set of secret data, for example, a truly randomly generated number. In addition, the seed can be associated or "mapped" to another data set, such as a device identifier for a device in the system. A seed mapped in this way can be referred to as a "device secret" and can be combined with the device identifier to increase key generation during a subsequent step. A device can be assigned to a device identifier from multiple sources, including a device serial number, a serial number for an internal device component, or any unique and categorizable identifier after that. Seeds and, equivalently, device secrets can be used in the system as a shared secret in support of the generation of cryptographic keys, such as the generation of symmetric keys. When multiple seeds are mapped to multiple devices through their respective device identifiers, the multiple mapped connections can be called “mapping”.
    [017] In specific embodiments of the invention, the system can provide a secure connection to an inter-device connection between a first device and a second device, in which a cloud architecture can be in communication with the second device. In these embodiments, the first device can have an identification of the first device and can store a seed. In addition, the cloud architecture can store the seed as a mapped device secret for identifying the first device, associating the seed with the first device. The identification of the first device can be a serial number of the first device. From the seed stored in the first device, a pairing key can be generated. The first device can transfer the identification of the first device in the inter-device connection to the second device. The second device can transmit the identification of the first device to the cloud architecture. The cloud architecture, in response, can generate a pairing key from the device secret associated with the identification of the first device and send the pairing key to the second device. With their respective identical pairing keys, the first device and the second device can complete a handshake to provide the secure connection, performing mutual authentication and cryptographic scheme negotiation.
    [018] The first device can transmit the identification, and any other information that can be used for the handshake with the second device, to the second device in several ways. According to the example provided directly above, information can be transmitted using the same inter-device connection, discussed elsewhere in this document, to which the secure connection will be added. However, the information can also be transmitted using other channels. The transmission of information from the first device may depend on the hardware of the first device. For example, if the first device had a display screen, the information can be displayed to a user and manually entered on the second device. As another example, the first device could have an alternate wired or wireless connection to the second device to which the information can be delivered.
    [019] The first device, the second device and the cloud architecture can instantiate modules. Modules can implement specific approaches to the method steps described here. Module steps can be implemented using computer-readable, non-transitory media storage instructions that can be performed by a processor. Modules in communication devices can be configured to generate keys, establish and provide connections to other devices, negotiate communication protocols, and conduct other processes.
    [020] The first device, the second device and the cloud architecture can include hardware elements. Hardware elements can be touch screens, flat screens, touch panels, fingerprint readers, image sensors, microphones, speakers, batteries, processors, relative clocks, absolute clocks, card readers, volatile memories, non-memory volatiles and other auxiliary components. Hardware elements can enable wired and wireless communications, including web servers, modems, configurable radios, wireless transceivers, antennas, radio frequency front ends comprising encoders-decoders, multiplexers, switches, amplifiers and filters, in addition to other communication components . Hardware elements targeted for wired communications can be implemented in conjunction with any type of data cable, including ethernet, token ring, coax, optical fiber, serial cable, Cat2, telephone cable, universal serial bus cable (USB) or others types of data cable used to send digital information. Alternatively, data cables can be specific for communicating video information, in which case the types of data cables can include video-s, component video, DVI, HDMI, display port, CoaXPress and MHL and other types of data. video cable. Hardware elements targeted for wireless communications can support any standard type or frequency band, including standards such as the Wi-Fi / IEEE 802.11 series, EDGE, EV-Do, Flash-ODFM, GPRS series, HSPA, Lorawan, LTE, RTT, UMTS series, WiMAX, 6LoWPAN, Bluetooth series, IEEE 802.15.42006, Thread, UWB, USB wireless, ZigBee, ANT + and other communication standards.
    [021] The first device, the second device and the cloud architecture can have secure enabling elements that are resistant to breach or compromise attacks. An example of a secure element is a secure processor that can generally function as a standard processor with reduced performance, and has been changed to limit unnecessary functions for improved security. An application-specific integrated circuit (ASIC) or a discrete integrated circuit can be designed to perform only safe specific functions and not other general purpose functions and therefore can be a safe element. A distinct general-purpose processor can be modified to be a secure element, or include a secure element, through certain modifications, such as the physical partitioning of the secure element from the general hardware elements in the same chip. A secure element can also be placed in the same package as a general processor, but be located in a different physical chip than that package. Alternatively, a secure element can be secured by removing vulnerable communication paths to prevent communication with unsafe elements. Secure elements can have secure storage independent of standard storage. Secure storage can be physically and logically isolated from the system with which the secure element is configured to operate. In another approach, a secure element can receive limited memory to prevent manipulation of stored data, modules or protocols and exclude the possibility of malicious code being installed or executed locally. In one example, secure storage can be in the range of two hundred bytes to eight kilobytes. Safe elements can be permanently installed on the circuit board or the chip pack on which they are mounted to prevent physical tampering and removal. Safe elements can be made even safer by tamper-resistant packaging, such as an opaque cover, a tear-resistant mesh, a tamper sensor, a secure element that excludes secure storage if a tamper is detected, or an element that destroys the secure element if there is a removal from the system.
    [022] In specific embodiments of the invention, the first device can be an application device and the second device can be a personal user device. An application device can be targeted for one or a few applications, and can be optimized with minimal components to approximate the minimum manufacturing cost. An application device can be configured to serve a specific purpose in conjunction with a personal user device and, therefore, can be a “peripheral” of the personal user device. In one example, an application device may have a secure element that can store private data and instantiate a connection protocol module and connection protocol key generator. In another example, an application device may have a data reader with a data processing module, the last of which is instantiated by a secure element and communicatively connected to said data reader. In a third example, an application device may include a secure element that is a discrete integrated circuit and includes less than twenty kilobytes of secure, writable storage. The second device can be a personal user device, such as a smartphone, tablet, laptop, or other communication device that can enable cryptographic and authentication protocols. A personal user device can run many types of applications. For example, a personal user device may have a processor that instantiates a connection protocol module and an operating system. In the same example, the personal user device can connect communicatively with another device, as well as participate in authentication and establish a secure connection with that device. Throughout this invention, the terms "first" and "second" device will be used to refer to those devices, where the use of these terms should include, but not be limited to, the examples provided above, where the first device is an application device and the second device is a personal user device.
    [023] Advantages accumulate for the modalities of the invention where the first device is a peripheral with limited secure memory and a symmetric matching key can be implemented for the handshake to provide a secure connection with the second device. Using a symmetric matching key for the authentication and encryption handshake, few bytes of data stored on the first device are required by omitting the certificates that would be required for key generation during the handshake, as in a public key scheme / private where private keys can be larger than authentication certificates. At the same time, the advantages accumulate in the approaches in which a seed is used to pair key generation. In these approaches, the seed is never exposed outside the secure device. As such, in systems where the secure element in the first device has sufficient processing resources to perform a cryptographic process using a pre-injected seed, a desirable trade-off between storage-oriented secure memory partitions against cryptographic calculations is provided by reducing the secure storage required for symmetric key generation. In addition, the peripheral may be a low-cost device provided by an entity responsible for ensuring the connection, and the second device may be a readily available device that is provided by a user. These particular cases are particularly adaptable to certain approaches described here, as the pairing key generation approach is exposed only on secure peripherals and the cloud architecture, which provides a high degree of control to the peripheral provider, allowing users select a wide range of devices to replace the second device.
    [024] Approaches that use symmetric matching keys provide specific advantages over approaches that require the use of certificates with respect to authentication methods, in addition to key generation. Thus, the secure connection between the first device and the second device can be added using a TLS handshake that uses symmetric keys instead of certificates. Using the X.509 public / private key standard to instantiate a secure TLS connection may require that both devices provide certificates for mutual authentication, where each certificate can be in the order of eight hundred to one thousand and six hundred bytes in size. In practice, using asymmetric digital signature methods such as Rivest-Shamir-Adleman (RSA), digital signature algorithm (DSA) or elliptical curve encryption (ECC), the first device and the second device would have to authenticate each with a string from two to four certificates, with the possibility that the corresponding private keys used for those certificates are even larger than the certificates themselves, further burdening the secure memory of the secure element of the first device. Symmetric keys can alleviate this memory load, comprising key data sizes in the order of 8 to 16 bytes through the use of smaller initial TLS handshake packets in mutual authentication and less calculations in the key generation process using the seed. Such approaches avoid public / private key processing times, which can be in the order of a hundred milliseconds. The benefits of lower secure storage load and faster cryptographic processing can provide greater benefit over its already distinct advantages, in secure systems designed for secure payments that must also process secure payment keys and payment authentication certificates with secure elements already limited.
    [025] In specific embodiments of the invention, the benefits accrue when the system includes a cloud architecture that stores the identity of a set of devices, such as a set of peripheral devices. For example, a manufacturer could create a line of peripherals that use the system to securely connect to any smartphone. These approaches are beneficial because the cloud architecture can monitor the set of devices and keep a record of compromised devices. In one example, a first device can be a peripheral device that has become suspicious or known to be compromised, as in the case where it was stolen. To avoid insecure communications with the first compromised device, these findings can be reported in the cloud architecture. Thus, the first device under suspicion can be registered as a device that has been compromised. The transmission of the pairing key from the cloud architecture to the second device, as mentioned above, can be preconditioned on the first device that is not registered as compromised in the cloud architecture. This can prevent the second device from being activated to authenticate and generate a secure connection to a device that is compromised.
    [026] Specific modalities of the invention exhibit certain benefits where the first device does not require a user interface with high functionality or does not need a user interface at all. Some device pairing schemes require user input of a shared secret to the application device to enable device pairing via a device interface. For example, one device could display a code, and the code would then be manually entered into a user interface on a second device. Mutual authentication and the provision of secure connections, through secure storage of the shared secret on the first device, do not require a user to provide information to the first device for the process to continue. As such, the first device can be a peripheral device as described above, with comparatively strict size and security requirements in relation to user devices, and can often be built without a user interface.
    [027] Fig. 1 illustrates a system 100 for adding a secure connection 111 to an interdisplay connection 110 between two discrete devices, for example, a first device 120 and a second device 130, in conjunction with a cloud architecture 140. The first device 120 can be a peripheral, an application device or an equivalent device type, of the second device 130. The second device 130 can be a personal user device or an equivalent device type. The inter-device connection 110 can be generated using a standard Bluetooth protocol using a first Bluetooth module 121 on the first device 120 and a second Bluetooth module 131 on the second device 130. The secure connection 111 can be instantiated as a TLS connection. The inter-device connection 110 and the secure connection 111 communicatively connect the first device 120 and the second device 130 in a bidirectional manner. Seeds and, equivalently, device secrets can be used in system 100 in support of the generation of pairing keys that can subsequently be used by the first device 120 and second device 130 during the handshake for mutual authentication and provision of the secure connection 111.
    [028] In specific embodiments of the invention, system 100 can have a first device 120 with a secure element 122 that stores a device secret, and cloud architecture 140 can store a mapping from an identification of the first device 120, as a hardware identifier, for the device secret. The secure element 122 may be a discrete secure processor. System 100 can also instantiate a first connection protocol key generator 123 and a second connection protocol key generator 141, in the first device 120 and cloud architecture 140, respectively. The first connection protocol key generator 123 and the second connection protocol key generator 141 can be configured to generate a pairing key using the seed. Key generators 123 and 141 can be implemented by secure elements that can be configured to securely store secret data sets and perform cryptographic operations, including the generation of a PSK. In one configuration, a secure element in communicative connection with a cloud architecture can store a cryptographic element, such as a key encryption key (KEK), used to encrypt seeds stored in the cloud architecture. Seed encryption schemes using a KEK may include, for example, advanced encryption standard (AES) or data encryption standard (DES) symmetric key algorithms. Therefore, a stored seed can be encrypted with a KEK to generate a PSK, where the PSK can be configured to be a pairing key. In addition, the first connection protocol key generator 123 and the second connection protocol key generator 141 can both be PSK generators compatible with TLS protocols. It is noted that the PSK or pairing key, after generation, can be used subsequently in additional processes, for example, a TLS handshake in which the PSK can be used as an input to allow calculations that ultimately derive the keys used directly for authentication and encryption.
    [029] Advantages accumulate in specific modalities where the seed is combined with other information specific to the device in the cryptographic process used to generate the pairing key. A challenge in generating a secure symmetric matching key with limited memory and processing resources is the process of creating a large, truly random number. Typical algorithms for this task can have significant calculation capabilities if performed internally on the device. Alternatively, a key can be loaded into a certified key injection facility, or a remote equivalent of that, but in these environments, the amount of “switching” material available may be limited when the device is implanted. Combining device-specific data with the seed to generate the pairing key can alleviate this concern. For example, generating the pairing key using the seed can be a combination of the seed and additional device-specific data that is readily available for the device, such as hardware identifiers, serial numbers, and equivalent device data on the first device.
    [030] Efficient processing of secure and secret information in system 100 can be implemented by organizing the information in sets. When a seed set is mapped to a set of device IDs, the seed set can be called a set of device secrets. As such, the mapping can therefore include a set of device secrets and a set of identifications. In addition, the set of IDs, by correlating each ID to a unique device, can identify the set of devices 150. In some embodiments, cloud architecture 140 can store the set of device secrets and be configured to generate a set of pairing keys using that set of device secrets. Key generation can be performed with the second connection protocol key generator 141. Cloud architecture 140 can be communicatively connected to the set of devices 150 via a communicative Internet connection 113 to track the status of the generated pairing keys and stored in tandem with the associated set of devices 150. Control of the key pairs and the set of associated devices 150 at the cloud architecture level 140 provides benefits in allowing the invalidity of pairing keys and devices when they become compromised.
    [031] The process of facilitating the transfer of necessary information between the first device 120 and the cloud architecture 140 to generate the secure connection 111 between the first device 120 and the second device 130 can be mediated by the second device 130 to improve security. First, the second device 130 may be required to authenticate its identity on the cloud architecture server 140, for example, using an installed application to deliver a username and password combination, a PKI authentication scheme or other viable methods . If the second authentication of device 130 is successful, the first device 120 can transmit the identification of the first device to the second device 130 using the inter-device connection 110, after which the second device 130 can exchange the identification of the first device with the cloud architecture 140 in exchange for the pairing key. The transfer of the identification of the first device to the cloud architecture 140 by the second device 130 can be performed, for example, using a communicative network connection 112. The pairing key can be generated by the second connection protocol key generator 141, in part using the device secret mapped to the identification of the first device, and transmitted from cloud architecture 140 to the second device 130 in response to receiving the device identifier from the second device 130. Alternatively, the first device can send your own identity and an identity from the second device using a direct connection between the first device and the cloud architecture, at which point the cloud architecture will deliver the pairing key to the second device.
    [032] The system can be in a state where the second device 130 can be in possession and safely store the pairing key, and the first device can be in possession and safely store the pairing key generated by the first generator. connection protocol key 123. In this state, a first connection protocol module 124 instantiated by the secure element 122 of the first device 120, and a second connection protocol module 132 instantiated by a processor 133 in the second device 130, can both be configured to mutually authenticate and add secure connection 111 to interdisection connection 110, using their respective pairing keys. Processor 133 can instantiate an operating system 134. The first connection protocol module 124 and the second connection protocol module 132 can be TLS modules.
    [033] In specific embodiments of the invention, a data reader 125 can be on the first device 120. The data reader 125 can be configured for the secure reading of data from secure data sources. For example, data reader 125 can read secure data from: a data storage device, such as a USB drive; a device comprising a magnetic strip, such as a credit card; a device comprising an integrated circuit, such as an integrated circuit card (ICC); a user, like a user with a biometric; nearby field proximity communications (NFC) provided by a device, such as a smartphone; a bar code, such as identifying the bar code on a physical item; or an image, such as a personal check image. In each embodiment, the data reader 125 may take the form of a device or system for receiving secure data, for example, with reference to the above example modalities, a USB reader, a card reader, an ICC reader, a data device. NFC communications, a biometric reader, a barcode scanner or an image sensor. These examples show merely possible configurations of the data reader 125 and do not limit the modalities that fall within the full scope of the invention. A data processing module 126, instantiated in the secure element 122, can subsequently receive the data via a communicative connection with the data reader 125. The data processing module 126 can interpret analog signals received from the data reader 125 and convert them into digital information. The data processing module 126 can also encrypt the received information and control the transfer of information out of the secure element 122. The first device 120 is configured to transmit digital information to the second device 130 using the secure connection 111.
    [034] In specific embodiments of the invention, methods for adding a secure connection can be performed using a one-time password (OTP) method that generates an encryption key with a finite validity period. The key validity period can be any period of time, such as the duration of a transaction, the length of a login session, or a predetermined and fixed period of time. Benefits follow from implementing an OTP key generation method as the limited key validity period minimizes the opportunity for an attacker to use a MITM replay or replay attack, in which a valid data packet may be deliberately delayed or improperly repeated to induce a safety defect. OTP methods described herein can be applied to the connection protocol key generators in the first device 120 and in the cloud architecture 140.
    [035] Fig. 2 illustrates a system 200 for implementing an OTP key encryption method that may require specific modules and elements, in addition to the modules and elements inherited from system 100. The first device 120 may have a first clock of real time 227 which can be instantiated in the secure element 122 and can generate a first time stamp. The first device 120 may also have a first connection protocol key generator 223 which is configured to generate a pairing key from a device secret using the first time stamp of the first real-time clock 227. In one example , a pairing key embedded in the first timestamp can be an OTP key. Cloud architecture 140 can instantiate a second real-time clock 242 which can generate a second time stamp. The real time can be loaded on the first device 120 in a secure resource before the device is deployed. Since the 227 real-time clock is real-time, it can be used in cryptographic approaches synchronized with cloud architecture 140 for the rest of its life, as long as the 227 real-time clock is not disturbed. Cloud architecture 140 can also have a second connection protocol key generator 241 that is configured to generate a pairing key from a device secret using the second time stamp from the second real-time clock 242. In a For example, the pairing key embedded in the second time stamp may be an OTP key. When using the first connection protocol key generator 223 and the second connection protocol key generator 241 using a device secret and a time stamp to generate pairing keys, PSKs, TLS PSKs or equivalent encrypted keys, these keys they can acquire the qualities of an OTP key and a limited time validity.
    [036] In specific embodiments of the invention, OTP key generation methods can contain several steps that are identically followed by the first device 120 and the cloud architecture 140 to generate a symmetric set of matching keys. The following steps described below are an example of the set of multiple identical steps described above. In a first step, the key data sets to be used by the key generator, such as a seed or device secret, can be provisioned. Provisioning this information to the first device 120 can be conducted while the device is in a secure key injection facility or remotely using a remote key injection protocol. In a second step, the OTP key generation algorithm and the parameters of the algorithm can be chosen. In one example, the algorithm can be a hash-based message authentication code (HMAC) key generation algorithm. In another example, the algorithm parameters can include: a key generation interval that defines a time when a generated key can become invalid and a new one must be generated; a secure hashing algorithm, such as from a series of SHA cryptographic hash functions published by the United States National Institute of Standards and Technology that operate mathematically on the device's secret data sets to create a hash output used as source data for generating keys; a truncation length that determines the amount of source data to be used, which must be less than the length of the hash output; and other parameters used for key generation. In a third step, the OTP key generation algorithm can identify the data that will be used as a seed, which can be a device secret. In a fourth step, a time stamp can be generated by a real time clock. In one example, the real time quoted in the time stamp can be defined as the current time of the Unix era, which is the time elapsed in seconds from the beginning of January 1, 1970, coordinated universal time. In a fifth step, the pairing key can be calculated using the OTP key generation algorithm using the selected parameters. In one example, the generated OTP pairing key can be in binary format.
    [037] Fig. 3 illustrates an example of an OTP 300 key generation method according to the generation of a pairing key by a connection protocol key generator. Method 300 can begin with provisioning the switching data sets 301 used by the key generator, such as a seed or device secret with additional device identifier information. Then, the instantiation of the OTP 302 key generation algorithm can proceed. The algorithm can be chosen from a set of algorithms during step 302 if multiple algorithms are available in the set. The OTP generation algorithm can be any viable algorithm, such as a standard request for comments (RFC) method, as developed by the Internet Engineering Task Force. In some modalities of method 300, the HMAC algorithm can be chosen as the OTP key generation algorithm. In an example of implementing the HMAC algorithm, the parameters include the hash function, h, the device secret, S, and the generated real-time time stamp, T. The algorithm can import the 303 parameters needed to define generation execution of keys. Finally, the pairing key can be generated 304 by calculating the OTP algorithm, where the pairing key can be configured to be usable as a PSK for TLS protocols. When applied to the key generator modules used in system 200, the specific implementation of method 300 may vary. However, certain mechanisms need to be implemented identically to ensure that the key generator module in cloud architecture 140 and the first device 120 agree on which implementation to apply at any time. In some approaches, cloud architecture 140 and first device 120 receive instructions before generating a pairing key as to which implementation to apply to the next generated key.
    [038] In specific approaches to the invention, cloud architecture 140 may include elements and modules that improve the functionality and security of the methods and systems described herein. Cloud architecture 140 can include a hardware security module (HSM). HSMs can be similar to secure elements, as they can provide layers of security unavailable for generic elements. However, HSMs are differentiated from the secure elements themselves, because HSMs are designed to store, generate, process, categorize and transfer encryption keys. Thus, HSMs can include any type of secure element to accomplish these purposes, such as a secure processor, secure data storage, encryption modules, decryption modules, key generators, clocks, secure input elements to receive remote control commands and other secure elements. HSMs can be installed locally on a device as a secure element. Alternatively, HSMs can be operated remotely and transfer secure information, such as an encryption key, to the system of interest over a secure connection. HSMs with advanced functionality can be used in a system back-end architecture, such as a cloud architecture 140, where the system's back-end design is not limited, for example, hardware component size, processing or storing battery power. The modules, elements and hardware used in one modality to implement an HSM can be considered equivalent to another HSM modality, regardless of the location of the HSM installation, such as a device or cloud architecture, unless otherwise defined. It is also noted that, while an HSM is an integral part of the security of its elements and modules and, therefore, of the system, the process requires absolutely no HSM to perform the steps of the method described. These steps can be performed by a generic processor supported by the necessary elements and modules, if the security requirements of the application are maintained.
    [039] In specific approaches to the invention, cloud architecture 140 can include a database to securely store the information needed to record the collection of keys, devices, device identifiers, device secrets and related tracking and provisioning information . The database can remain secure as long as it resides outside HSM through a data encryption implementation, for example, using a key encryption key technique described below. Cloud architecture 140 can include a web server to securely receive, store, process and provide information from cloud architecture 140 to another device in the system, such as the second device 130. The web server can establish a secure connection, for example , forming a secure TLS connection with a secure hypertext transfer protocol (HTTPS), with another device after the connecting device has provided the necessary credentials, such as a user identifier. After the secure connection is established, private information, such as pairing keys, can be transmitted over the secure connection.
    [040] Fig. 4 illustrates an exemplary cloud architecture 140 in system 400 that can include an HSM, a database and a web server for generating and transmitting a secure key involving cloud architecture 140, in addition to the legacy modules and elements of systems 100 and 200. In one example, a hardware security module 443 can store a key encryption key and instantiate the second connection protocol key generator 241 to allow the generation of a pairing key in the cloud architecture 140. KEKs can provide a layer of security in the data sets that are used to generate encryption keys in later encryption steps, such as a pairing key or PSK. A KEK used in this way can complement the encryption steps implemented, for example, by a second connection protocol key generator 241 that uses an OTP encryption algorithm with a second time stamp of a second real-time clock 242. A KEK can be used to encrypt a device secret in cloud architecture 140 to create an encrypted device secret. Since the pairing key can be generated with a device secret associated with a mapping to a device identifier, a database 444 in cloud architecture 140 can contain the information necessary to provision key generator 241 at the appropriate time. As such, database 444 can contain the mapping while storing the device secret as an encrypted device secret and retrieving the encrypted device secret using the device identifier. The encrypted device secret must be decrypted before being used for key generation and can be decrypted by the decryption module 445 as instantiated in the hardware security module 443. After decryption, the second connection protocol key generator 241 on Cloud architecture 140 can be used, with the device secret, to generate the pairing key. In one example, the second real-time clock 242 can be instantiated in the cloud architecture 140 and turned off in the hardware security module 443. In another valid example, the second real-time clock 242 can be instantiated in the hardware security module 443 and retain the same functionality with additional security.
    [041] In one example, cloud architecture 140 may contain a web server 446 configured to receive a device ID from a second device 130 to authenticate the second device 130, it can access the mapping from database 444 using the device identification and can transmit the pairing key to the second device 120 after accessing the mapping to forward the TLS handshake, the mutual authentication process and provisioning a secure connection 111 to the inter-device connection 110 between the first device 120 and the second device 130. In another example, second device 130 can have two separate TLS connection protocol modules 432 and 435. TLS connection protocol module 432 can be instantiated on processor 133 to provision secure connection 111 according to the methods described for the second connection protocol module 132, where secure connection 111 can be a TLS connection. The TLS 435 connection protocol module, a third system protocol module 400, can also be instantiated on processor 133 while remaining functionally separate from the TLS connection protocol 432, or it could be instantiated elsewhere on the second device 130. The module connection protocol TLS 435 can form a connection 412 to the web server 446 from the second device 130. Connection 412 can be authenticated and encrypted using HTTPS protocols.
    [042] Authentication of the second device 130 to the web server 446 on cloud architecture 140 may allow for unique security mechanisms, such as preventing the cloud architecture from provisioning a pairing key to a malicious party. In some embodiments of the invention, authentication of the second device 130 for cloud architecture 140 can be implemented using an application installed on the second device 130. The application can be configured to be managed by operating system 134 and instantiated by processor 13 using the system operational 134. The application can be implemented using a method to verify the user identity of the second device 130. The application can use the elements and modules on the second device 130 to assist in the user identification task. The application can, for example, perform the second authentication of device 130 by asking the user to enter a username and password using display device and input device technologies, such as a touchscreen display, which can be relayed to the 446 web server for authentication. The process by which the user provides private user information to authenticate is generally called knowledge-based authentication. Related methods may include different or additional security issues, such as personal identification numbers (PINs), questions from personal users answered in advance and accessible to the 446 web server, or even pictographic questions. In other authentication processes, the application can request a user's biometrics, such as fingerprint, voice command, retinal scan, or facial recognition image, provided to the application through the sensor elements on the second device 130. In another scenario, since the second device 130 is usually not overloaded by the same element and module restrictions as the first device 120, the second device 130 can implement standard authentication and encryption protocols, such as using certificates and private / public key encryption . Authentication by the application can incorporate the second connection protocol module 132, or equivalent TLS 432 connection protocol module, to be part of the application. In another example, application authentication can incorporate the TLS 435 connection protocol module. As part of the application, the protocol module can be used to exchange the identification of the first device 120 with a pairing key after the authentication of the second device. 130 through the application, for example over connection 412. In other words, the transmission of the pairing key of cloud architecture 140 in this exchange can be preconditioned in the authentication process of the application of the second device 130.
    [043] Communications between the second device 130 and the cloud architecture 140 can be conducted by the TLS 435 connection protocol module on the second device 130 with the web server 446 on the cloud architecture 140. The TLS 435 connection protocol modules can provision connection 412 with standard wireless protocols as described above, including TLS protocols. The TLS protocol can use HTTPS to establish a secure connection. In some embodiments, the second device 130 may be a smartphone and the TLS 435 connection protocol module may be the native TLS connection protocol module configured by the original equipment manufacturer (OEM) or the installation of the original operating system. If these TLS 435 connection protocol models are used to communicate with cloud architecture 140, additional layers of cryptographic security can be implemented in the TLS connection provided by the module, when required by the sensitive nature of the private data being carried by the device 130 In alternative modalities, the TLS 432 connection protocol module can be used to communicate with the 446 web server. In these modalities, the TLS 432 connection protocol module can be instantiated by the application and can be activated to connect to the web server. 446 for a connection other than a websocket protocol.
    [044] Fig. 5 illustrates the 500 system that can perform secure payment transactions with secure payment modules and secure storage, in addition to the modules and elements inherited from systems 100, 200 and 400. These secure payment and secure storage modules can also support cryptographic and authentication processes, such as the TLS handshake between the first device 120 and the second device 130. To this end, the first device 120 can have a secure payment logic module 526 in secure element 122. The logic module secure payment method 526 can incorporate the properties of data processing module 126 that allow data to be received and processed from data reader 125. Since data reader 125 can receive payment information in the data provided to it, the payment logic module insurance 526 can receive and additionally process secure payment information in accordance with secure payment standards, such as the security standard of d payment card industry. The second device 130 can process secure information using an application 536, which can also function as described above in relation to the TLS connection protocol modules. Application 536 can be instantiated by processor 133 and instantiated payment logic module 537 which can work in conjunction with secure payment logic module 526 over secure connection 111. In some embodiments of the invention, the first device 120 can receive payment information related to a payment transaction in data reader 125, and process payment information in secure payment logic module 526 to be able to send payment logic module 537 over secure connection 111. The information Payment methods can be processed by the application 536 with the payment logic module 537 and relevant parts of the payment information can be sent to another location, for example, through a connection established by one of the TLS connection protocol modules.
    [045] In commercial configurations where secure payments are used and interactions with the customer are expected, the improved usability of the 500 system is desired. To improve the processing speed at which a secure connection can be provisioned, the first device 120 can assist in the processing time required to conduct a handshake by providing a key identity suggestion whenever the secure protocol allows it. The suggestion can be generated on the first device 120 as a data set that includes data from the first device 120 together with the identification of the first device. For example, the suggestion may be a combination of the device identifier together with a time stamp. The time stamp can be provided by a secure clock operating on the first device, such as clock 227 in the examples above.
    [046] In some embodiments of the invention, security modules can be added to allow secure and local storage of critical and private data used for the TLS handshake. In cloud architecture 140, hardware security module 443 can include secure storage module 547 for storing a KEK used to generate a TLS PSK or pairing key. In the first device 120, the secure element 122 may include the secure storage module 528 for storing a loaded device secret. In some approaches where a device secret is used to generate a PSK for a TLS handshake, secure storage can be less than twenty kilobytes.
    [047] Hardware security module 443 in cloud architecture 140 is a configurable module. In one example, hardware security module 443 can be configured to operate without a control module, suitable for instances where a small set of cryptographic commands is required. In a different example, hardware security module 443 can receive commands with a control module, such as a control computer, to allow the execution of stored programs. In this example, the control computer can accommodate one of many configurations, as an isolated module in communicative connection with the secure storage module 547 or, alternatively, fully incorporated into the 546 web server.
    [048] In some embodiments of the invention, methods can be implemented to check the safety status on the second device 130, in order to interrupt operations, if it has been compromised. The application 536 on the second device 130 can transmit location telemetry, for example, GPS coordinates, to the cloud architecture 140 for the time period of installing the application 536 to store a credible location data set for use by the second device 130 with the first device 120 on which machine learning algorithms can learn. If it is determined from the analysis of the learning algorithm that a second device 130 has been compromised, cloud architecture 140 can be instructed to interrupt the transmission of the pairing key to the second device 130.
    [049] Although the specification has been described in detail with respect to specific modalities of the invention, it will be appreciated that those skilled in the art, upon gaining an understanding of the foregoing, can readily conceive of changes, variations and equivalents to these modalities. Any of the method steps discussed above can be conducted by a processor that operates with a computer-readable non-transitory medium storing instructions for these method steps. The computer-readable medium may be memory within a personal user device or accessible network memory. The terminal can be a computer terminal, a smartphone, a point of sale terminal, a repeater, a beacon, a sensor or any other device that collects and transmits secure information. Although the examples in the description were generally targeted at TLS, any number of communication protocols with similar characteristics in terms of providing security and authentication for a two-way flow of communication could be used instead. These and other modifications and variations of the present invention can be practiced by those skilled in the art, without departing from the scope of the present invention, which is more particularly established in the appended claims.
    权利要求:
    Claims (28)
    [0001]
    1.System (100) for provisioning a secure connection (111) to an inter-device connection (110), characterized by the fact that it comprises: a first device (120) having a secure element (122), in which the secure element (122) ): (i) stores a device secret; (ii) instantiate a first connection protocol module (124); and (iii) instantiating a first connection protocol key generator (123); a cloud architecture (140) that: (i) stores a mapping from the device secret to an identification of the first device (120); and (ii) instantiating a second connection protocol key generator (141); wherein the first connection protocol key generator (123) and the second connection protocol key generator (141) are both configured to generate a pairing key using the device secret; wherein the first connection protocol key generator (123) generates the pairing key using a first time stamp generated on the first device (120); wherein the second connection protocol key generator (141) generates the pairing key using a second time stamp generated in the cloud architecture (140); and a second device (130) which: (i) has a processor (133) which instantiates a second connection protocol module (132); (ii) it is communicatively connected to the first device (120) through the inter-device connection (110); (iii) it is configured to receive the identification of the first device from the first device (120); and (iv) it is configured to exchange the identification of the first device for the pairing key with the cloud architecture (140) through a network connection (112); wherein the pairing key is a symmetric pre-shared key generated using identical steps on the first device (120) and the cloud architecture (140); wherein the first connection protocol module (124) and the second connection protocol module (132) are configured to: (i) authenticate each other using the pairing key; and (ii) adding the secure connection (111) to the interdevice connection (110) using the pairing key.
    [0002]
    2. System (100), according to claim 1, characterized by the fact that it further comprises: a data reader (125) in the first device (120); and a data processing module (126) instantiated by the secure element (122) and communicatively connected to the data reader (125) to receive data; wherein the first device (120) is configured to transmit data from the data reader to the second device (130) using the secure connection (111).
    [0003]
    3.System (100), according to claim 2, characterized by the fact that: the second device (130) is a personal user device; the processor (133) instantiates an operating system; the first device (120) is a peripheral of the second device (130); the secure element (122) is a discrete secure processor; the first (124) and second (132) connection protocol modules are transport layer security (TLS) modules; the first (123) and second (141) connection protocol key generators are TLS pre-shared key generators (PSK); the pairing key is a PSK; and the secure connection (111) is a TLS connection.
    [0004]
    4.System (100), according to claim 1, characterized by the fact that it also comprises: a first real-time clock (227) instantiated in the secure element (122); wherein the first connection protocol key generator (123) is configured to use a first time stamp from the first real-time clock (227) to generate the pairing key from the device secret; a second real-time clock (242) instantiated in the cloud architecture (140); and wherein the second connection protocol key generator (141) is configured to use a second time stamp from the second real-time clock (242) to generate the pairing key from the device secret.
    [0005]
    5.System (100), according to claim 1, characterized by the fact that the cloud architecture (140) further comprises: a hardware security module (443) storing a key encryption key and instantiating the second generator connection protocol key (141); a database (444) containing the mapping, where the database (444) stores the device secret as an encrypted device secret; and a decryption module instantiated in the hardware security module (443) and configured to decrypt the encrypted device secret using the key encryption key.
    [0006]
    6. System (100), according to claim 1, characterized by the fact that the cloud architecture (140) further comprises: a web server (446) configured to receive the identification of the first device (120) from the second device (130), access the mapping using the identification of the first device (120), and transmit the pairing key to the second device (130) after accessing the mapping.
    [0007]
    7. System (100), according to claim 6, characterized by the fact that it further comprises: an HTTPS connection between the web server (446) and the second device (130); and a third connection protocol module instantiated on the second device (130) and configured to form the HTTPS connection with the web server (446); where the second and third connection protocol modules are separate TLS modules.
    [0008]
    8. System (100), according to claim 1, characterized by the fact that it also comprises: an operating system and an application of the operating system that are instantiated by the processor (133) in the second device (130); wherein the second connection protocol module (132) is part of the application; wherein the application is configured to authenticate the second device (130) to the cloud architecture (140); and in which the cloud architecture (140) is configured to precondition the exchange of the identification of the first device (120) for the pairing key with an authentication of the second device (130) through the application.
    [0009]
    9. System (100), according to claim 1, characterized by the fact that the secure element (122): is a discrete integrated circuit; and includes less than 20 kilobytes of secure, writable storage.
    [0010]
    10. System (100), according to claim 1, characterized by the fact that: the mapping includes a set of device secrets and a set of identifications; the identification set identifies a set of devices (150); the cloud architecture (140) is communicatively connected to the set of devices (150) through the internet; and the second connection protocol key generator (141) is configured to generate a set of matching keys using the set of device secrets.
    [0011]
    11. Method for provisioning a secure connection (111) to an inter-device connection (110) between a first device (120) and a second device (130), characterized by the fact that it comprises: storing a device secret in a secure element ( 122) in the first device (120); storing a mapping from the device secret to a device identifier of the first device (120) in a cloud architecture (140); generating a first time stamp on the first device (120); generate a second time stamp in the cloud architecture (140); generating a pairing key using: (i) a first connection protocol key generator (123) in the secure element (122); (ii) the first time stamp; and (iii) the device secret; generate the pairing key using: (i) a second connection protocol key generator (141) in the cloud architecture (140); (ii) the second time stamp; and (iii) the device secret; transmitting the pairing key from the cloud architecture (140) to the second device (130) in response to receiving the device identifier; mutually authenticate the first (120) and second (130) devices using the pairing key as stored in the first device (120) and as stored in the second device (130); and adding the secure connection (111) to the interdevice connection (110) using the pairing key as stored in the first device (120) and as stored in the second device (130); wherein the pairing key is a symmetric pre-shared key generated using identical steps in the first device (120) and in the cloud architecture (140).
    [0012]
    12. Method according to claim 11, characterized by the fact that it further comprises: receiving data using a data reader (125) on the first device (120); and transferring data from the first device (120) to the second device (130) using the secure connection (111).
    [0013]
    13. Method according to claim 12, characterized by the fact that: the second device (130) is a personal user device with an operating system; the first device (120) is a peripheral of the second device (130); the secure element (122) is a discrete secure processor; the first and second connection protocol key generators are TLS pre-shared key generators (PSK); the pairing key is a PSK; and the secure connection is a TLS connection.
    [0014]
    14. Method, according to claim 11, characterized by the fact that it further comprises: generating a first time stamp using a first real-time clock (227) on the secure element (122); generating a second time stamp using a second real-time clock (242) in the cloud architecture (140); wherein the generation of the pairing key using the first connection protocol key generator (123) uses the first time stamp; and wherein the generation of the pairing key using the second connection protocol key generator (141) uses the second time stamp.
    [0015]
    15. Method according to claim 11, characterized by the fact that it further comprises: encrypting the device secret in the cloud architecture (140) to create an encrypted device secret; retrieving the encrypted device secret from a cloud architecture database (444) (140) using the device identifier; decrypt the encrypted device secret using a hardware security module (443) in the cloud architecture (140) before generating the pairing key using the second connection protocol key generator (141) in the cloud architecture (140) and the device secret; and wherein the second connection protocol key generator (141) is instantiated by the hardware security module (443).
    [0016]
    16. Method according to claim 11, characterized by the fact that it further comprises: receiving the device identifier from the second device (130) using a web server (446) of the cloud architecture (140); wherein the transmission of the pairing key from the cloud architecture (140) to the second device (130) uses the web server (446).
    [0017]
    17. Method according to claim 16, characterized by the fact that it further comprises: forming an HTTPS connection between the web server (446) and the second device (130) using a TLS connection protocol module instantiated on the second device (130); wherein a separate TLS protocol module adds the secure connection (111) to the interdevice connection (110).
    [0018]
    18. Method according to claim 11, characterized by the fact that it further comprises: instantiating an application using an operating system on the second device (130); authenticate the second device (130) to the cloud architecture (140) using the application; and preconditioning a transmission of the pairing key from the cloud architecture (140) to the second device (130) with an authentication of the second device (130) through the application.
    [0019]
    19. Method according to claim 11, characterized by the fact that the secure element (122): is a discrete integrated circuit; and includes less than 20 kilobytes of secure, writable storage.
    [0020]
    20. Method according to claim 11, characterized by the fact that it further comprises: storing a set of device secrets in the cloud architecture (140); and generating a set of matching keys using the device's secret set in the cloud architecture (140); where the mapping includes a set of identifications; and wherein the set of identifications identifies a set of devices (150).
    [0021]
    21. Method, according to claim 11, characterized by the fact that it also comprises: generating a time stamp using a real time clock (242) in the cloud architecture (140); generating a key identity suggestion on the second device (130) using the time stamp and device identifier; and transmitting the key identity suggestion from the second device (130) to the first device (120) while adding the secure connection (111) to the interdevice connection (110).
    [0022]
    22.Method, according to claim 11, characterized by the fact that it also comprises: registering a third device as compromised in the cloud architecture (140); and preconditioning a transmission of the pairing key from the cloud architecture (140) to the second device (130) on the first device (120) not being registered as compromised in the cloud architecture (140).
    [0023]
    23. Method according to claim 11, characterized by the fact that it further comprises: generating the inter-device connection (110) using a first Bluetooth module (121) on the first device (120) and a second Bluetooth module (131) on the second device (130); transmitting the device identifier from the first device (120) to the second device (130) using the inter-device connection (110); and transmitting the device identifier from the second device (130) to the cloud architecture (140) using a network connection (112).
    [0024]
    24. Method, according to claim 11, characterized by the fact that it further comprises: generating a first time stamp using a first real-time clock (227) on the secure element (122); wherein the generation of the pairing key using the first connection protocol key generator (123) uses the first time stamp; and where the pairing key is a single-use pairing key (OTP).
    [0025]
    25. System (100), comprising: a first device (120); a second device (130) with an inter-device connection (110) to the first device (120); characterized by the fact that the system (100) further comprises: a secure element (122) in the first device (120) storing a device secret; a cloud architecture (140) storing the device secret and a mapping from the device secret to a device identifier of the first device (120); a first connection protocol key generator (123) on the secure element (122) configured to generate a pairing key using the device secret; wherein the first connection protocol key generator (123) generates the pairing key using a first time stamp generated on the first device (120); a second connection protocol key generator (141) in the cloud architecture (140) configured to generate the pairing key using the device secret; wherein the second connection protocol key generator (141) generates the pairing key using a second time stamp generated in the cloud architecture (140); a first connection protocol module (124) instantiated by the secure element (122); a second connection protocol module (132) in the second device (130); an application on the second device (130) that receives the pairing key from the cloud architecture (140) and instantiates the second connection protocol module (132); wherein the cloud architecture (140) is configured to transmit the pairing key to the second device (130) in response to receiving the device identifier; wherein the first connection protocol module (124) and the second connection protocol module (132) are configured to: (i) mutually authenticate using the pairing key; and (ii) adding a secure connection (111) to the interdevice connection (110) using the pairing key; and wherein the pairing key is a symmetric pre-shared key generated using identical steps on the first device (120) and the cloud architecture (140).
    [0026]
    26. System (100), according to claim 25, characterized by the fact that it further comprises: a data reader (125) in the first device (120); and a data processing module (126) instantiated by the secure element (122) and communicatively connected to the data reader (125) for receiving data; wherein the first device (120) is configured to transmit data from the data reader to the second device (130) using the secure connection (111).
    [0027]
    27. System (100), according to claim 26, characterized by the fact that: the second device (130): (i) is a personal user device; and (ii) has a processor; the processor (133) instantiates an operating system; the first device (120) is a peripheral of the second device (130); the secure element (122) is a discrete secure processor; the first (124) and second (132) connection protocol modules are transport layer security (TLS) modules; the first (123) and second (141) connection protocol key generators are TLS pre-shared key generators (PSK); the pairing key is a PSK key; and the secure connection (111) is a TLS connection.
    [0028]
    28.System (100), according to claim 26, characterized by the fact that it also comprises: a first real-time clock (227) instantiated in the secure element (122); wherein the first connection protocol key generator (123) is configured to use a first time stamp from the first real-time clock (227) to generate the pairing key from the device secret; a second real-time clock (242) instantiated in the cloud architecture (140); and wherein the second connection protocol key generator (141) is configured to use a second time stamp from the second real time clock (242) to generate the pairing key from the device secret; and where the pairing key is a single-use pairing key.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR102019015369B1|2021-03-16|systems and method for provisioning a secure connection to an inter-device connection
    KR102138283B1|2020-07-27|Method of using one device to unlock another device
    US9467430B2|2016-10-11|Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware
    US10554636B2|2020-02-04|Lightweight encrypted communication protocol
    TWI600307B|2017-09-21|Method and device for secure communications over a network using a hardware security engine
    US10979412B2|2021-04-13|Methods and apparatus for secure device authentication
    EP3047601B1|2019-07-10|Technologies for synchronizing and restoring reference templates
    CN104160656A|2014-11-19|System and method for connecting client devices to a network
    EP3175380A1|2017-06-07|System and method for implementing a one-time-password using asymmetric cryptography
    US20170214664A1|2017-07-27|Secure connections for low power devices
    US10958664B2|2021-03-23|Method of performing integrity verification between client and server and encryption security protocol-based communication method of supporting integrity verification between client and server
    US20200351107A1|2020-11-05|Secure authentication of remote equipment
    KR20170012161A|2017-02-02|METHOD FOR OPERATING COMMUNICATION CLIENT INSTALLED IN IoT DEVICE AND IoT DEVICE INCLUDING THE CLIENT
    WO2019120231A1|2019-06-27|Method and device for determining trust state of tpm, and storage medium
    WO2014177055A1|2014-11-06|Establishment of communication connection between mobile device and secure element
    US11153080B1|2021-10-19|Network securing device data using two post-quantum cryptography key encapsulation mechanisms
    US20220050933A1|2022-02-17|Nvme over fabrics authentication system
    US11050570B1|2021-06-29|Interface authenticator
    US11277444B2|2022-03-15|System-on-chip for performing virtual private network function and system including the same
    US20210250167A1|2021-08-12|Derived Keys for Connectionless Network Protocols
    KR20210046615A|2021-04-28|System for transporting messages through virtual private network
    KR20200032945A|2020-03-27|System-on-chip for performing virtual vprivate network funtion and system comprising the same
    TW201929476A|2019-07-16|Encrypted verification method
    CN110912685A|2020-03-24|Establishing a protected communication channel
    CN112425116A|2021-02-26|Intelligent door lock wireless communication method, intelligent door lock, gateway and communication equipment
    同族专利:
    公开号 | 公开日
    US10326797B1|2019-06-18|
    EP3633913B1|2021-03-03|
    CA3061233A1|2020-04-03|
    CN110995642A|2020-04-10|
    AU2019202163B1|2019-10-31|
    CA3061233C|2021-09-21|
    EP3633913A1|2020-04-08|
    BR102019015369A2|2020-02-18|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    CN101166259B|2006-10-16|2010-11-10|华为技术有限公司|Mobile phone TV service protection method, system, mobile phone TV server and terminal|
    CN101393628B|2008-11-12|2012-08-08|飞天诚信科技股份有限公司|Novel network safe transaction system and method|
    CN101583124B|2009-06-10|2011-06-15|大唐微电子技术有限公司|Authentication method and system of subscriber identity module and terminal|
    CN102111759A|2009-12-28|2011-06-29|中国移动通信集团公司|Authentication method, system and device|
    JP5861081B2|2010-06-03|2016-02-16|パナソニックＩｐマネジメント株式会社|Semiconductor device and semiconductor relay using the same|
    BR112013000494B1|2010-07-09|2020-10-27|Paypal, Inc|method, unit of payments and system for conducting payments with electronic credits|
    WO2013177325A2|2012-05-22|2013-11-28|Level 3 Communications, Llc|Methods and systems for allocating and provisioning computing resources|
    US10025920B2|2012-06-07|2018-07-17|Early Warning Services, Llc|Enterprise triggered 2CHK association|
    EP2725758A1|2012-10-29|2014-04-30|Gemalto SA|Method for mutual authentication between a terminal and a remote server via a third-party portal|
    DE102013203257A1|2013-02-27|2014-08-28|Bundesdruckerei Gmbh|Reading an attribute from an ID token|
    US10880741B2|2013-07-23|2020-12-29|Capital One Services, Llc|Automated bluetooth pairing|
    US9704160B2|2014-09-22|2017-07-11|Mastercard International Incorporated|Trusted execution environment for transport layer security key pair associated with electronic commerce and card not present transactions|
    US9436819B2|2014-09-23|2016-09-06|Intel Corporation|Securely pairing computing devices|
    KR102294118B1|2014-10-21|2021-08-26|삼성전자주식회사|Apparatus and method and for connecting security|
    WO2016114842A1|2014-10-31|2016-07-21|Convida Wireless, Llc|End-to-end service layer authentication|
    US20160179855A1|2014-12-23|2016-06-23|Yahoo! Inc.|Ubiquitous content access and management|
    TW201700213A|2015-06-30|2017-01-01|國立中興大學|Machine tool capable of improving thermal error by improving the thermal deformation of main shaft and yet without increasing structural complexity to enhance the processing precision|
    US10229448B2|2015-12-16|2019-03-12|Paypal, Inc.|Network of personalized devices determining data for shopping predictions|
    US10172000B2|2016-03-17|2019-01-01|M2MD Technologies, Inc.|Method and system for managing security keys for user and M2M devices in a wireless communication network environment|
    US10334437B2|2016-06-09|2019-06-25|Canary Connect, Inc.|Secure pairing of devices and secure keep-alive|CN104765999B|2014-01-07|2020-06-30|腾讯科技（深圳）有限公司|Method, terminal and server for processing user resource information|
    US10693633B2|2018-11-19|2020-06-23|Cypress Semiconductor Corporation|Timestamp based onboarding process for wireless devices|
    US10726681B1|2019-07-26|2020-07-28|Clover Network, Inc.|Advanced hardware system for self service checkout kiosk|
    US11228572B2|2019-09-09|2022-01-18|Ahp-Tech Inc.|Data transmission system and method with high security|
    WO2021162427A1|2020-02-10|2021-08-19|삼성전자 주식회사|Electronic device and method for performing peer to peer service in electronic device|
    US20210279703A1|2020-03-06|2021-09-09|Fiserv, Inc.|Point of sale device with secure connection between security meshes|
    WO2022006493A1|2020-07-02|2022-01-06|Cal-Chip Electronics Specialty Products, Inc.|Connected secure key redistribution system and method|
    WO2022012960A1|2020-07-16|2022-01-20|Signify Holding B.V.|Location-based encryption and decryption|
    CN112640506A|2020-07-28|2021-04-09|华为技术有限公司|Bluetooth node pairing method and related device|
    法律状态:
    2020-02-18| B03B| Publication of an application: publication anticipated [chapter 3.2 patent gazette]|
    2020-06-16| B07A| Application suspended after technical examination (opinion) [chapter 7.1 patent gazette]|
    2021-01-05| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|
    2021-03-16| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 25/07/2019, OBSERVADAS AS CONDICOES LEGAIS. |
    优先权:
    申请号 | 申请日 | 专利标题
    US16/150,625|US10326797B1|2018-10-03|2018-10-03|Provisioning a secure connection using a pre-shared key|
    US16/150,625|2018-10-03|
    [返回顶部]